The present invention relates to anchoring of a mobile node in a wireless system.
Such anchoring is needed in a wireless system comprising a plurality of radio access networks having, for example, heterogeneous access technologies. It is particularly needed when handling mobility in such a wireless system.
As a non limitative example, such anchoring is provided in evolved system architectures which are in the process of standardization in the 3GPP (3rd Generation Partnership Project) and 3GPP2.
In particular, anchoring is provided in the EPS (Evolved Packet System), detailed in the technical specifications 3GPP TS 23.402 V1.3.0 and 3GPP TS 23.401 V1.2.1, both published in September 2007, and which make use of a network-based mobility management mechanism, such as Proxy MIP or PMIP as defined in the Internet-Draft, draft-ietf-netlmm-proxymip6-01.txt, “Proxy Mobile IPv6”, published on Jun. 18, 2007 by the IETF (Internet Engineering Task Force) or GTP (GPRS Tunnelling Protocol, where GPRS stands for General Packet Radio Service) as defined for instance in the technical specification 3GPP TS 29.060 V7.5.0 published in September 2007.
FIG. 1 illustrates anchoring of a mobile node MN in an EPS system where PMIP is used in a non-hierarchical manner. It will be noted that GTP or any other network-based mobility management mechanism could be suitable as well. This system is a simple wireless network comprising two radio access networks (RANs) RAN1 and RAN2, a home gateway H-GW, an authenticator Auth and a home authentication authorization and accounting server H-AAA.
In the illustrated example, RAN1 and RAN2 each comprise a mobile access gateway (MAG) functionality (also referred to as the proxy mobility agent (PMA) functionality in some earlier versions of the above mentioned Internet-Draft “Proxy Mobile IPv6”). They are thus capable of performing the signaling and of doing the mobility management on behalf of the mobile node MN. As to the H-GW, it comprises a local mobility anchor (LMA) functionality (also referred to as the home agent (HA) functionality in some earlier versions of the above mentioned Internet-Draft “Proxy Mobile IPv6” because of its similarity with the HA functionality defined in the Request for Comments RFC 3775 “Mobility Support in IPv6” published in June 2004 by the IETF (see section 8.4 in particular)).
The MN perceives simple IP (Internet Protocol) service and is assigned a home address HoA by the LMA functionality of the H-GW, as defined in the above mentioned publications.
In this scenario, when the MN, having a radio link with RAN1, attaches to the system of FIG. 1, it is authenticated with the H-AAA via the authenticator Auth. During the access authentication procedure, e.g. by the H-AAA and/or by Auth, H-GW is dynamically assigned to the MN.
The MN is then registered with the H-GW. This can be achieved by using the MAG functionality of RAN1, which sends a binding update message to H-GW on behalf of the MN. More detail on the binding update message can be found in the above mentioned Internet-Draft “Proxy Mobile IPv6” (see section 6.9.1 in particular).
After those operations, the H-GW can be considered as the assigned mobility anchor for the MN. And connectivity is established, in the form of a PMIP tunnel 2 between RAN1 and H-GW.
Afterwards, the MN moves to RAN2, meaning that a new radio link is opened between the MN and RAN2, whereas the radio link with RAN1 may be closed. If a communication was held by the MN with RAN1, it must then continue with RAN2.
When the MN moves to RAN2, a MN context containing all relevant information about the communication and about the manner traffic is routed within the system (e.g. security information, an address of the H-GW, etc.) is transferred from the source RAN1 to the target RAN2. This transfer is made possible by the presence of a context transfer (CT) interface between RAN1 and RAN2, which can be a direct interface 1 or which can go through other devices, such as one or several mobility management entities (MMEs).
After the context transfer, RAN2, by virtue of its MAG functionality, can establish connectivity to H-GW, for instance by sending a PMIP binding update message to the H-GW. The MN's communication can then go on via RAN2, as a PMIP tunnel 2 is thus created between RAN2 and H-GW.
FIG. 2 illustrates another anchoring of a mobile node MN in an EPS system where PMIP is used in a hierarchical manner. In this example also, GTP or any other network-based mobility management mechanism could be suitable as well.
In this hierarchical scenario, the anchoring is with a visited serving gateway rather than with the home gateway. The visited serving gateway is thus the one that contains the LMA functionality facing the radio access networks each including a MAG functionality. In addition, it contains a MAG functionality facing the H-GW.
The hierarchical scenario is typically used in roaming scenarios because it minimizes mobility related signaling across the roaming boundary. In addition, anchoring in the visited serving gateway allows for continuity of lawful intercept of user's traffic.
The system of FIG. 2 comprises three radio access networks, among which RAN1 and RAN2 share a context transfer (CT) interface (direct interface 4 or through one or several MMEs), whereas RAN2 and RAN3 do not have a context transfer (CT) interface therebetween.
As an example, RAN1 may be a 3GPP radio access network comprising one or several eNode-B (eNB) and RAN2 may be a non-3GPP radio access network (e.g. Wimax, CDMA2000, etc.).
It is assumed that the MN, having a radio link with RAN1, first attaches to the visited subsystem to which the gateway V-GW1 belongs. It is authenticated with the H-AAA via the authenticator Auth1. During the access authentication procedure, e.g. by the H-AAA and/or by Auth1, H-GW is dynamically assigned to the MN.
Moreover, Auth1 selects V-GW1 as a local mobility anchor. It also provides V-GW1 with an MN identifier and a H-GW address and sends a V-GW1 address to RAN1.
For registration of the MN, RAN1, which has a MAG functionality, establishes connectivity to V-GW1 on behalf of the MN, for instance by sending a binding update message to V-GW1. V-GW1 then establishes connectivity to H-GW, for instance by sending a binding update message to H-GW.
This initial attachment procedure substantially corresponds to the one detailed in section 5.4.2.4.3 of the above mentioned TS 23.402, where MN corresponds to the UE (User Equipment), V-GW1 is the Serving GW and H-GW is the PDN (Packet Data Network) GW.
At the end of this procedure, PMIP tunnels 3 and 5 are established between RAN1 and V-GW1 on the one hand, and V-GW1 and H-GW on the other hand. Those PMIP tunnels ensure connectivity between the MN and H-GW.
When the MN moves to RAN2, a V-GW1 address is transferred onto the CT interface 4 from RAN1 to RAN2, as part of the MN context. The target RAN2 can then register with V-GW1, rather than with another visited serving gateway, such as V-GW2.
As a result, a PMIP tunnel 3 between RAN2 and V-GW1 as well as a PMIP tunnel 5 between V-GW1 and H-GW can be used for carrying traffic to and from the MN.
A problem occurs however when the MN moves between radio access networks which are not connected through a CT interface (directly or through one or several MMEs), such as RAN2 and RAN3 of FIG. 2.
Indeed, assuming that the MN has a radio link with RAN2 and then moves to RAN3, there is no existing means for allowing the target RAN3 to register with the same visited serving gateway which was used by the source RAN2, namely V-GW1. Instead, another visited serving gateway which can belong to another subsystem, namely V-GW2, is assigned as a new local anchor for the MN.
There is a need to keep the same visited serving gateway as a local anchor even when the MN moves between base stations having no context transfer interface therebetween. This need is particularly acute for handling traffic to and from roaming users. If this need could be met, it would also avoid signaling to be transmitted and processed as far away as the home gateway H-GW.
The present invention fills this need.